>That wasn't my question, it was whether you have actually tried to use
>them for whatever purpose you want a HDR-Image for.

Not directly in povray. I toyed with a GI extension to a raytracer I wrote
with some friends (truetrace it was called, written *many* moons ago, dead
when I changed job) and, using a 16-bit integer color image as a source for
illumination and environment, I ran into troubles with outdoor scenery.
I was trying to immerse a somewhat reflective object in an actual ambient (a
fisheye photograph, taken outdoors on sunny day) and I could't get the
dynamic range right, due to the sun. Then I fished an old copy of Radiance
and took out the code for fp images. I ended using an ad-hoc solution,
using a shared exponent for three mantissas (1 normalized and 2
denormalized) which worked quite well. The discussion about a floating
point rep for color components reminded me of the thing and, trying to
recover the algorithms for fp colors, I stumbled on SGI's LogLuv color
encoding
(http://positron.cs.berkeley.edu/~gwlarson/pixformat/tiffluv.html), which
is far better.

>While HDR-Images can of course be used as environment maps this won't make
>environment mapping any more useful in a raytracer.  HDR-Images are
>certainly useful for various purposes in POV-Ray and there already is a
>patch supplying support for that, but environment mapping certainly isn't
>one of them.

Why not?
I mean why environment mapping wouldn't be useful?

I suspect that we didn't properly understand each other (surely my fault,
I'm browsing the newsgroups while I'm working and COBOL do things to your
brains after a while).

What you intend for environment mapping?

Alex

P.S.: *sigh* - COBOL...what a shame for me...

Can you imagine writing a ray-tracer in COBOL?
I mean, COBOL is Turing-equivalent, is it?

Heh, it wouldn't be too fast, but at least it would be accurate in
calculating expenses and taxes (provided your scene doesn't cross a century
while rendering :-)

Post a reply to this message